>From: der Mouse <mouse@Collatz.McRCIM.McGill.EDU> > >[spaf@cs.purdue.edu] >> I have yet to see evidence of this. Based on my conversations with >> personnel at various computer companies, the only thing full >> disclosure seems to do is (sometimes) encourage them to release bug >> fixes without quite as much testing. > >Personally, the biggest pro of full disclosure, and the reason I follow >bugtraq, is that as far as security patches go, I am my own vendor. Indeed! Those of us who labor with older versions of the OS (and/or a dearth of dollars with which to upgrade them) are in desperate need of full disclosure. Given the propensity of vendors to ignore all but the most recent whiz-bang version of their software, it has become al- most essential for any serious admin to create their own workarounds and/or patches. Consider, if you will, AT&T System V. Up until Release 3.2, AT&T pro- vided *wonderful* support; I received a nicely formatted Known Problem List (KPL) twice a year, and the good 3b2 folks at Lisle would even ans- wer questions from those folks without support contracts, if the problem was serious. The KPL stopped with 3.2; with SVR4, the NCR/ATT support teams are allegedly grepping the source for the error messages when users report bugs. Toss in the fact that many of us are running sys- tems orphaned when the ATT/NCR merger took place (the StarServer line), and full disclosure becomes truly important, if not downright essential. ObBug: As shipped, AT&T SVR4 3.1 for the StarServer E creates logfiles /tmp/rlogind and /tmp/ftpd. The rlogind logfile is harmless enough, but the ftpd logfile includes userids and passwords. By default, the files are world readable. Workaround: I could never find a patch from NCR/ATT. I created an empty /tmp/ftpd during boot, protecting it at 600. This does not prevent entries from being made, but it does keep the information (relatively) private. --Wes